這次我只在 Discord 實測了兩次完整流程。五種專案則用於自動化測試，兩者分開看，不把測試案例數量當成實機完成次數。

測試後發現，流程完成和方案寫得正確，需要分開檢查。有些方案已保存，內容卻還有句子沒寫完，或選了新方向，取捨紀錄仍留著舊方案。Review 甚至可能給高分，沒有抓到這些問題。

今天除了完整流程測試，也補上來源核對、草案完整性檢查與 Discord 顯示修正。這篇會說明測試怎麼安排，以及為什麼不能只看到「通過」就結束驗收。

兩次完整實測，還要回頭讀方案

兩次完整實測除了觀察流程能不能接續，也要讀 Agent 的發言、PM 草案，以及選擇方向後的候選方案。批准和保存是否正常，與內容有沒有滿足需求，是不同的檢查項目。

搭配品質檢查與回歸案例，可以看到幾種問題：方案引用不存在的第二輪、必要章節在句中結束，還有選擇 CLI 後，決策理由仍說 Web 超支才改 CLI。這些內容可能符合 JSON 格式，卻不適合直接交付。

逾時接續也保留在程式與自動化測試中。Creative 的單次期限由 60 秒調為 180 秒，仍維持兩次總嘗試；討論中斷後可從 /resume 接續已保存的步驟，不必重跑成功的 Agent。調長期限並不代表所有輸入都不會再逾時。

審查前，先把原始需求交給 Review

如果 Review 只讀草案，就容易跟著草案自述判斷。模型說「已滿足需求」，但沒看到原始驗收條件，審查者也無從逐條核對。

現在審查輸入會帶上原始需求、需求變更、使用者選擇與允許引用的來源。Bot 組合會議需求時，也把預算、交付期限與驗收條件一起傳入，避免只保留需求摘要。

以 FAQ 測試案為例，要求是未知問題一律顯示「轉人工處理」。如果某個選項改成只回「未找到答案」，看起來仍像合理客服功能，卻沒有滿足這份專案的驗收條件。

PM 套用選擇時也要同步檢查整份方案，包括摘要、五個章節與決策理由。只改執行計畫，其他地方仍保留舊方向，使用者讀到的就會是兩套互相矛盾的方案。

目前程式另外針對已重現的 CLI 矛盾加上窄範圍檢查：需求或選擇明確要求 CLI 且禁止即時 Web 時，不能還保留「先用 Web，超支才改 CLI」的理由。其他語意矛盾仍需要模型與人工核對。

決策來源不能讓模型自己編

PM 草案有採用、拒絕與折衷的取捨紀錄，也會標示引用哪位 Agent、哪一輪的發言。

但只執行第一輪時，曾出現「Finance Agent 第2輪」。來源字串雖然有填，卻沒有對應的討論。

services/proposal_quality.py 現在從已完成且有輸出的步驟建立來源表：

def source_catalogue(record):
    return sorted({f"{step.agent_name} 第{step.round_number}輪"
        for step in record.steps
        if step.round_number in {1, 2} and step.output_data is not None
        and getattr(step.status, "value", step.status) == "completed"})

這份表以 allowed_sources 傳給 PM 與 Review。產生草案或套用使用者選擇後，再由程式核對引用；不存在或無法確定輪次的來源會被拒絕，沿用有限重試，不保存成可批准的候選稿。

這項檢查只能確認「那位 Agent 確實在那一輪完成發言」，不能保證模型對發言內容的解讀正確。追溯來源與理解來源，仍是兩件事。

字數符合上限，句子卻沒有寫完

另一個問題是草案停在「完成測試，並整理包含防重」。欄位非空，長度也合法，但讀者不知道後面要防止什麼。

今天沒有直接提高生成 Token 上限。PM 的章節改以 120～180 字為目標，要求用完整短句收尾；Finance 每項以 40～60 字為目標，在原有 80 字限制內留出空間。

另外用 incomplete_sections() 檢查已重現的未收尾特徵，以及接近 240 字上限卻沒有結句的章節。下面節錄判斷部分：

ended = text.endswith(tuple("。！？.!?；;"))
dangling = re.search(
    r"(?:並|以及|包含|包括|以便|例如|交付驗收：本|整理包含防重)$", text
)
if not ended and (dangling or len(text) >= 230):
    findings.append(section)

發現必要章節疑似截斷時，即使模型回覆「通過」，程式也會改為「需要修改」，完整度給 2 分，指定 PM 補完。

這是針對已知問題的檢查，沒有做到所有欄位的完整語意驗證。短標籤不會只因沒有句號就被退回；其他 Agent 的句子仍可能需要人工閱讀。

優先目標和硬性驗收要分開

重測還發現，Review 會把「創新優先」當成隱含驗收條件。使用者選擇保守但可行的方案，也可能因此被要求修改。

目前的 ReviewIssue 用 basis 標明問題依據。違反原始需求或使用者選擇的問題放在 issues；優先目標與歷史參考的改善意見放在 advisories。

例如未知問題必須轉人工，是硬性要求；建議再增加新穎的互動方式，則是改善建議。創意分數可以偏低，但必要項目達標且沒有硬性問題時，不必為此退修。

自動修改仍最多一次，由程式決定：

revision_allowed = result.status == "需要修改" and request.revision_count == 0

用完額度後，剩餘問題照樣保留，不會為了走完流程強行改成通過。加權品質分數也只是參考指標，不能取代必要項目的審查結果。

把 Discord 裡的重複訊息一起整理

同一場會議的狀態卡，現在依伺服器、頻道、會議與頁次識別，優先更新原訊息。帶決策按鈕的卡片不套用這個快取，以免影響操作版本。

目前程式還用 StatusMessageStore 保存訊息 ID 與已發送的用量簽章。重啟後可以依索引找回狀態卡；舊卡沒有索引時，只查指定頻道最近 100 則訊息。無法確認舊訊息是否存在時，不盲目補發。這是目前的程式補強，報告中的重測只驗證同一次 Bot 執行內的更新與去重。

PM 用量也只在成功發送後記住簽章，相同生成數據不因接續 Review 再貼一次，新生成的數據仍會顯示。

/projects 則把 tuple 與 list 都轉成條列，並依專案狀態顯示下一步。已完成的專案不再一律提示 /start。

修正後，用錯誤案例確認它真的會退回

還準備三個刻意有問題的草案，交給真正的 qwen3.5:9b 與 ReviewAgent：缺少未知問題轉人工、選 CLI 卻保留 Web 優先方向，以及執行計畫句中截斷。三案都回傳「需要修改」，也沒有取得額外的自動修改額度。

另外的 FAQ 品質重測用來檢查退修與候選稿，不列為新增一次完整批准流程。這個虛構案例要求 10 題已知回答附正確編號，10 題未知全部轉人工。選擇 C「規則式優先策略」，經一次修改後，候選稿保留驗收要求，來源對應真正第一輪，程式未發現必要章節截斷。

DAY 28 用自動化測試涵蓋五種專案，實機則只做了兩次完整流程，再搭配品質回歸檢查補上來源、文字完整性與顯示問題。這個範圍還不足以證明所有需求都能穩定處理。往後驗收除了看能不能執行，還要回到原始需求逐條讀方案；Review 的分數可以協助檢查，最後仍不能省掉這一步。